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1 Introduction 

One of the distinguishing features of functional programming is the widespread 
use of combinators to construct programs. A combinator is a function which 
builds program fragments from program fragments; in a sense the program- 
mer using combinators constructs much of the desired program automatically, 
rather than writing every detail by hand. The freedom that functional languages 
provide to manipulate functions — program fragments — as first-class citizens 
supports combinator programming directly. 

Some combinators, such as the well-known list-processing operators map 
and filter, encapsulate generally useful program constructions and may appear 
in almost any functional program. Others are tailored to particular application 
areas, and are often collected into libraries that enable applications in that 
area to be built quickly and easily. For example, parsing is an application 
area that has been extensively studied. Given an appropriate library of parsing 
combinators, a parser for the grammar 

G::=aGb\c 

might be programmed in Haskell [Hud92, PH96] as 

gram = symbol "a" 'cat' gram 'cat' symbol "b" ■#■ symbol "c" 

A note on syntax: in Haskell, function application is written without brackets, 
so symbol "a" denotes a call of the function symbol with argument "a", and any 
function of two arguments may be used as an infix operator by enclosing it in 
back-quotes. In this example, symbol is a function which constructs a parser 
that accepts just the given token, 'cat ' is a binary operator which combines 
two parsers into a parser that runs both in sequence, -#• is a binary operator 
which combines two parsers into one which tries both as alternatives 1 , and the 
entire declaration is a recursive definition of a parser gram which recognises the 
non-terminal G. 

x We follow the fairly widespread convention that long operator names are typeset with 
their characters overlapping, so that they look like a single name. In reality, -40- is just +++. 
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Although the idea of programming with combinators is quite old, the de- 
sign of combinator libraries has been profoundly influenced in recent years by 
Wadler's introduction of the concept of a monad into functional programming 
[Wad90, Wad92, Wad95]. We shall discuss monads much more fully in the next 
section, but for now, suffice it to say that a monad is a kind of standardised 
interface to an abstract data type of 'program fragments'. The monad inter- 
face has been found to be suitable for many combinator libraries, and is now 
extensively used. Numerous benefits flow from using a common interface: to 
take just one example, Haskell has been extended with special constructions to 
make the use of monads particularly convenient. 

It is therefore a matter for some concern when libraries emerge which cannot, 
for fundamental reasons, use the monad interface. In particular, Swierstra and 
Duponcheel have developed a very interesting library for parsing LL-1 grammars 
[SD96], that avoids a well-known inefficiency in monadic parsing libraries by 
combining the construction of a parser with a 'static analysis' of the program 
so constructed. Yet Swierstra and Duponcheel's optimisation is incompatible 
with the monad interface. We believe that their library is not just an isolated 
example, but demonstrates a generally useful paradigm for combinator design 
that falls outside the world of monads. We shall look more closely at their idea 
in section 3. 

Inspired by Swierstra and Duponcheel's library, I sought a generalisation of 
the monad concept that could also offer a standardised interface to libraries of 
this new type. My proposal, which I call arrows, is the subject of this paper. 
Pleasingly, the arrow interface turned out to be applicable to other kinds of 
non-monadic library also, for example the fudgets library for graphical user 
interfaces [CH93], and a new library for programming active web pages. These 
applications will be described in sections 6 and 9. 

While arrows are a little less convenient to use than monads, they have 
significantly wider applicability. They can therefore be used to bring the benefits 
of monad-like programming to a much wider class of applications. 

2 Background: Library Design Using Monads 

What, then, is a monad? In Haskell, the monad interface can be defined as a 
class: 

class Monad m where 
return :: a — > to a 
(»=) :: m a — > (a — > m b) — > m b 

Read this as follows: a parameterised type to is a monad if it supports the two 
operations return and (pronounced 'bind') with the types given. Intuitively, 
we think of a value of type m a as representing a computation with result of type 
a — a program fragment. The return operation constructs a trivial computation 
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that just delivers its argument as its result. The operation combines two 
computations in sequence, passing the result of the first as an argument to the 
second — hence the type of the second argument of »= : it is a function that 
constructs the second computation, rather than just a computation. 

2.1 An Example: A Monad to Manage Failures 

For example, consider the type Maybe defined by 

data Maybe a = Just a | Nothing 

(This declaration introduces a new parameterised type Maybe with two construc- 
tors, Just and Nothing. A value of type Maybe a is either of the form Just x, 
where a: is a component of type a, or of the form Nothing.) This type can be 
used to represent possible failure: a function which intuitively returns a result 
of type t, but may fail, can be defined to return a result of type Maybe t instead, 
where Nothing represents failure. This idea can be used more conveniently if we 
define a combinator library to take care of failure handling. 

To do so, we declare the type Maybe to be a monad; that is, we give imple- 
mentations of return and for this type. In Haskell, we write 

instance Monad Maybe where 
return a = Just a 
x 3*= / = case x of 

Just a — > / a 
Nothing — > Nothing 

where x >*= / fails immediately, without calling /, if its first argument x fails. 

Using these combinators we can write functions which handle failure prop- 
erly without any explicit tests for Just and Nothing. For example, the following 
function adds together two possibly-failing integers, failing itself if either argu- 
ment does: 

add :: Maybe Int — > Maybe Int — > Maybe Int 
add x y = x >*= Xa — > 

y >= Xb -> 

return (a + b) 

(The layout here is well suited to monadic programs, but may be confusing at 
first: the body of the A-expression Xa — > ... extends to the end of the entire 
right hand side!) 

To complete a useful library for failure handling we must add at least a 
combinator to cause a failure, for example 

fail :: Maybe a 
fail = Nothing 
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Now we can treat the Maybe type as abstract, and write programs that cause 
and propagate failures just using the operators fail, return and ;>=, without any 
explicit dependence on the way that failures are represented. 

2.2 Another Example: A Monad to Manage State 

As another example, an updateable state can be modelled in a purely functional 
language by passing each function the current contents of the state as an ad- 
ditional parameter, and returning the possibly modified state as a part of each 
function's result. To do so by hand is tedious and error-prone, but fortunately 
we can encapsulate the state passing mechanism in a combinator library by 
using a monad. 

In this case we represent a computation with result type a and a state of 
type s by a value of the type 

newtype StateMonad s a = SM (s — > (a, s)) 

(The Haskell newtype declaration introduces a new type isomorphic to an 
existing one, where the constructor names the isomorphism). For any state 
type s, the partially applied type StateMonad s (which denotes a parameterised 
type with one remaining parameter) is a monad: 

instance Monad (StateMonad s) where 
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With these definitions, we can write programs which pass around a state just 
in terms of return and »=; there is no need to manipulate the state explicitly. 
Notice that must pass the modified state s' returned by its first argument 
to its second, rather than the original state, and must return the modified state 
returned by its second argument as part of its own result. If one attempts to 
pass a state around by hand, rather than by using combinators, then it is very 
easy to forget a ' somewhere, with strange bugs as a result. 

To complete a library for state passing we must provide combinators for 
reading and modifying the state. For example, 

fetch :: StateMonad s s 
fetch = SM(\s -> (s,s)) 

store :: s — > StateMonad s () 
store x = SM (As (Q,a;)) 
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Now the StateMonad type can be made abstract, and stateful programs can be 
written just in terms of the combinators. For example, a function to increment 
a counter: 

tick :: StateMonad Int Int 
tick = fetch 3= An — > 

store (n + 1) »= A() -» 

return n 

2.3 Monadic Parsing Combinators 

In practice, combinator libraries are usually based on monads providing a combi- 
nation of features. For example, a parser for values of type a can be represented 
by the type 

newtype Parser s a = P ([s] — > Maybe (a. [s])) 

where s is the type used to represent symbols in the parser's input, and [s] is 
Haskell's notation for the type list-of-s. Such a parser is invoked by applying its 
representation to a list of symbols to parse; its result indicates whether or not 
parsing was successful, and in the event of success contains both the value parsed 
and the remaining, unparsed input. For example, a parser which recognises a 
particular symbol can be defined by 

symbol :: s — > Parser s s 

symbol s = P (Xxs — > case xs of 

[] -» Nothing 

(x : xs 1 ) — > if x = s then Just (s. xs 1 ) else Nothing) 

This parser fails if the input is empty or begins with the wrong symbol, and 
succeeds with one symbol consumed from the input otherwise. 

This representation of parsers supports a combination of failure handling and 
state passing, where the state is the unparsed input. It can be declared to be a 
monad just like the Maybe and StateMonad types above — see Wadler's articles 
for details. Further combinators can then be added to build up a complete 
library for parsing based on this monad. 

2.4 Why Use Monads? 

We have now seen that monads can be used as a basis for combinator libraries, 
but why should they be used? Why have monads become so ubiquitous in 
Haskell programs today? 

One reason, of course, is that using monads simplifies code dramatically. It 
should be clear that writing a parser with explicit tests for failure and explicit 
passing of the input here and there, would be much more labour intensive than 
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writing one in terms of symbol, return and ;>=. However, this is an advantage of 
using any combinator library to encapsulate coding details, and does not argue 
for using monads in particular. 

Another reason for using monads is that they offer a design guideline for 
combinator libraries: it is often a good start to begin by defining a suitable 
monad. For example, it is fairly clear that a library for parsing should include a 
combinator to invoke two parsers in sequence, but there are many possible ways 
in which such a combinator might handle the two parsers' results. In some early 
parsing libraries the two results were paired together, in others the sequencing 
combinator took an extra parameter, a function to combine the results. The 
monadic operator 3= is more general than either of these: both may be easily 
defined in terms of »=. but the converse is not true. By basing a parsing 
library on a monad, the designer gives the user more flexibility than these ad 
hoc alternatives. Indeed, we know from experience that the monadic interface 
gives the library user great power. 

On the other hand, the monad interface also gives the implementor of a com- 
binator library flexibility, because there are so many possible implementations. 
We have already seen three examples of monads; in fact, using monad trans- 
formers [KW92, LHJ95], we can systematically construct an infinite variety of 
monads. A systematic approach to monad design helps the implementor to find 
an appropriate type to base a combinator library on, but also helps to make 
the library 'future proof. Namely, should a future extension of the library re- 
quire a change in the representation of, say, parsers, then the implementor can 
rest assured that there are a myriad alternatives. To put it another way, the 
monad interface itself does not constrain the choice of monad type very much 
at all; it exposes very little of the internal workings of the library to the rest of 
the program. Consequently monads help the library maintainer to upgrade a 
combinator library without forcing changes in the code that uses it. 

Finally, the fact that the monad operations return and are overloaded in 
Haskell permits us to write generic monadic code, which can be used together 
with any library based on a monad. A growing collection of such functions are 
provided in the standard Haskell library. For example, we can generalise the add 
function above (for adding two possibly-failing integers) into a generic function 
which applies any binary operator to the results of two computations. 

UftM2 :: Monad m=^(a— >6— >-c)— >-ma— >mc 
UftM2 op x y = i>Ao-> 

y »= \b -> 

return(x 'op' y) 

(The Monad m =>■ in the type of UftM2 is a context, and means that this function 
may be used for any monad type m) . Now the 'cat ' operator on parsers that 
we saw in the introduction can be defined simply as 

cat = UftM2 (-H-) 
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(where -H- is Haskell's concatenation operator for lists). 

Generic code of this sort represents functionality that the designer of an 
individual combinator library no longer needs to provide: simply by basing the 
library on a monad, one gains access to a host of useful functions for free. This 
in turn may significantly reduce the work required to produce each new library. 

Taken together, these arguments provide rather compelling reasons for us- 
ing monads in combinator design; it is no wonder that they have become so 
ubiquitous. 

2.5 Further Parsing Combinators 

Let us pursue our example of combinators for parsing a little further. One of 
the things a parser can do is to fail; to enable us to express this we define a 
combinator which always fails. In fact, very many monads support a notion of 
failure, and so it is useful to overload the failure operator, just as we overloaded 
monadic return and »=. In Haskell this is done via a predefined class 

class Monad m => MonadZero to where 
zero :: m a 

to be read as follows: a parameterised type m is a MonadZero if it is a Monad, 
and additionally supports the operation zero. The implementation of zero for 
parsers is then defined by 

instance MonadZero Parser where 
zero = P (As — > Nothing) 

Moreover, many monads which support failure also support a choice com- 
binator, which tries two alternative ways to perform a computation, using the 
second if the first one fails. Haskell defines a predefined class 

class MonadZero m => MonadPlus to where 
(-H-) :: to a — > m a — > rn a 

and the implementation for parsers is 

instance MonadPlus Parser where 
P a-H-P b = P (As ->• case a s of 

Just (x, s') — > Just (x, s') 
Nothing — > b s) 

This is one of the fundamental building blocks of a parsing library: every 
interesting grammar defines some non-terminals via alternatives. But unfor- 
tunately, this definition contains a serious space leak. That is, it causes the 
retention of data by the garbage collector much longer than one would naively 
anticipate, with the result that parsers built with this operator use much more 
space than one would reasonably expect. 
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The problem is actually inherent to backtracking parsers. By inspection, 
the input to be parsed, s, cannot be garbage collected while the first parser a 
is running, because if a eventually fails, then s must be passed to b. In a lazy 
language such as Haskell, it is the very act of running parser a which forces the 
list of tokens s to be constructed, perhaps by reading from a file. Provided a 
fails quickly, without forcing the evaluation of many elements of s, then little 
space is used. But if a actually succeeds in parsing a large part of the input s, 
then a great deal of space may be used to hold these already-parsed tokens, just 
in case a eventually fails and b needs to be invoked. Ironically, in practice a and 
b usually recognise quite different syntactic constructs, so that if a succeeds in 
parsing many symbols then b will almost certainly fail as soon as it is invoked. 
Saving the input for b is costly only when it is unnecessary! 

This problem has been known since combinator libraries for parsing were 
first proposed, and Wadler for example gives a partial solution in his 1985 
paper [Wad85]. But the solutions known for monadic parser libraries are only 
partial, and depend on the programmer using an additional combinator similar 
to Prolog's 'cut' operator, to declare that a parser need never backtrack beyond a 
certain point. Although monadic parser libraries work quite well in practice, the 
fundamental problem remains unsolved, which is really rather unsatisfactory. 

3 Swierstra and Duponcheel's Parsing Library 

In 1996, Swierstra and Duponcheel found a different way to solve this prob- 
lem. They restrict their attention to LL(1) parsers, in which choices between 
alternative parses can always be resolved by looking at the next token of the 
input. Their implementation of a-H-b can therefore choose between a and b im- 
mediately, and there is no need to save the input s in case the other alternative 
needs to be tried later. The space leak that other parsing libraries suffer from 
is completely cured. 

To implement this idea, Swierstra and Duponcheel need to be able to tell, 
given a parser, which tokens it might accept as the first in the input (and also 
whether or not it can accept the empty sequence of tokens) . This means that 
parsers can no longer be represented as functions, as they were in the previous 
section. Instead, they are represented as a combination of static information, 
which can be computed before parsing begins, and a parsing function, which 
can be optimised on the basis of the static information. Paraphrasing Swierstra 
and Duponcheel, we might define 

data StaticParser s = SP Bool [s] 

newtype DynamicParser s a = DP ([s] — > (a, [s])) 

data Parser s a = P (StaticParser s) (DynamicParser s a) 

The first component of a parser tells us whether it matches the empty string, 
and which tokens it can accept first, while the second component is a function 
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which does the actual parsing. For example, the combinator which accepts a 
particular symbol can be defined as 

symbol :: s — > Parser s s 

symbol s = P (SP False [s]) (DP (X(x : xs) -» (s, xs))) 

The dynamic parsing function need not test for an empty input, or check that 
the first symbol is s, because it will be invoked only when the preconditions 
expressed by the static part are satisfied. 

Now we can make use of the static information to define the choice combi- 
nator efficiently: 

instance MonadPlus Parser where 

P (SP empty 1 startersi) (DP pi)-H-P (SP empty 2 starters 2 ) (DP p 2 ) = 
P (SP (empty 1 V empty 2 ) (starter si-r\- starters?)) 
(DP (Xxs -» 
case xs of 

[] — > if empty 1 then p\ [] else p 2 [] 

x : xs 1 — > if x £ startersi then p\ (x : xs 1 ) else 
if x £ starters? then p 2 (x : xs') else 
if empty 1 then pi (x : xs') else p 2 (x : xs 1 ))) 

It is clear from this definition that the choice of whether to invoke p\ or p 2 is 
made directly, and once made cannot be revised, so there is no need to retain a 
pointer to the input, and consequently no space leak 2 . 

Just as the -H- operator computes the starter symbols and potential empti- 
ness of the parser it constructs, so must all of the other combinators. In most 
cases this is straightforward to do, but unfortunately in the case of it turns 
out to be impossible! To see why, recall the type which must have in this 
case: 

(3*=) :: Parser s a — > (a — > Parser s b) — > Parser s b 

Now, the static properties of the result of depend on the static properties 
of both the first and the second argument — for example, the combination can 
match the empty sequence only if both arguments can. Yet in the definition 
of while we have access to the static properties of the first argument, we 
cannot obtain the static properties of the second one without applying it to a 
value of type a. Such values will be constructed only during parsing, but for 
Swierstra and Duponcheel's idea to be useful we must compute the static parts 

2 However, this definition is not completely realistic. It assumes that the user of the library 
really does write an LL(1) parser, so that startersi and starters2 are disjoint. In a real 
implementation this would of course be checked. Moreover, the expensive tests of the form 
x £ startersi can be avoided by choosing a cleverer representation of parsers — see Swierstra 
and Duponcheel's article for details. 
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of parsers once and for all. before parsing begins. It is simply impossible to find 
a definition of which does this. 

Swierstra and Duponcheel's solution to this problem was to abandon the use 
of a monad: instead of ;>= they defined a different sequencing operator with the 
type 

(<$>) :: Parser s (a — > 6) — > Parser s a — > Parser s b 

This operator is perfectly adequate for expressing parsers, and poses no problem 
as far as computing static properties in advance of parsing is concerned. Nev- 
ertheless, the need to abandon the monad signature is worrying, for the reasons 
we discussed above. Useful as it is, Swierstra and Duponcheel's parsing library 
stands alone; it cannot, for example, be used with generic monadic functions. 

If this were an isolated case we might simply ignore it. But Swierstra and 
Duponcheel's idea is clearly much more widely applicable: to optimise a com- 
binator library, redefine the combinators to collect static properties of the com- 
putations they construct, and then use those static properties to optimise the 
dynamic computations. If we think of a library as defining a domain specific 
'language', whose constructions are represented as combinators, then Swierstra 
and Duponcheel's idea is to implement the language via a combination of a 
static analysis and an optimised dynamic semantics. We may clearly wish to 
do this very often indeed. But every time we do, the type of will make it 
impossible to use a monadic interface! 

It is this observation that motivated us to search for a generalisation of mon- 
ads, a generic interface for combinator libraries that fits a much wider class of 
applications. We will introduce the generalisation we found in the next section. 

3.1 On Category Theory 

Before we do so, we make a short digression on the subject of category the- 
ory. The concept of a monad was developed by category theorists long before it 
eventually found an application in functional programming. Some might find it 
surprising that something so abstract as category theory should turn out to be 
useful for something so concrete as programming. After all, category theory is, 
in a sense, so abstract as to be rather unsatisfying: it is 'all definitions and no 
theorems', almost everything turns out to be a category if you look at it long 
enough, to say something is a category is actually to say very little about it. 
The same is true of most categorical concepts: they have very many possible 
instantiations, and so to say that something is, for example, a monad, is to say 
very little. This extreme generality is one reason why it is hard for the beginner 
to develop good intuitions about category theory, but it is hardly surprising: 
category theory was, after all, developed to be a 'theory of everything', a frame- 
work into which very many different mathematical structures would fit. But 
why should a theory so abstract be of any use for programming? 
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The answer is simple: as computer scientists, we value abstraction! When 
we design the interface to a software component, we want it to reveal as little 
as possible about the implementation. We want to be able to replace the imple- 
mentation with many alternatives, many other 'instances' of the same 'concept'. 
When we design a generic interface to many program libraries, it is even more 
important that the interface we choose have a wide variety of implementations. 
It is the very generality of the monad concept which we value so highly, it is 
because category theory is so abstract that its concepts are so useful for pro- 
gramming. 

It is hardly surprising, then, that the generalisation of monads that we 
present below also has a close connection to category theory. But we stress 
that our purpose is very practical: it is not to 'implement category theory', it 
is to find a more general way to structure combinator libraries. It is simply our 
good fortune that mathematicians have already done much of the work for us! 

4 Arrows 

Returning to our problem, recall that Swierstra and Duponcheel were unable to 
implement 

(3*=) :: Parser s a — > (a — > Parser s b) — > Parser s b 

because its second argument is a function, and the only thing one can do with a 
function is apply it. Lacking a suitable value of type a to apply it to, they could 
not extract any static information from it, and therefore could not construct 
the static part of »='s result. 

Our solution is simply to change the representation of this argument. Rather 
than a function of type a — > Parser s b we will use an abstract type, which we 
will call an arrow from a to b. We solve Swierstra and Duponcheel's problem by 
choosing a representation for arrows which makes static properties immediately 
accessible. 

In fact there is no need to work with two abstract types, a monad type and 
an arrow type. Instead we will work purely with arrows. In general, an arrow 
type will be a parameterised type with two parameters, supporting operations 
analogous to return and Just as we think of a monadic type m a as repre- 
senting a 'computation delivering an a\ so we think of an arrow type a b c (that 
is, the application of the parameterised type a to the two parameters b and c) 
as representing a 'computation with input of type b delivering a c'; arrows make 
the dependence on input explicit. 

Just as Haskell defines a Monad class, so we shall define an Arrow class with 
analogous operators. But we must make dependence on an input explicit. Thus 
while the return operator, with type a — > m a, merely converts a value into a 
computation, its analogue for arrows, with type (b — > c) — > a b c, converts a 
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function from input to output into a computation. The analogue of 3= is just 
composition of arrows. We define 

class Arrow a where 
arr :: (6 — > c) — > a b c 
(^>) :: abc^acd^abd 

For any monad m, functions of type a — > m b are potential arrows. If we 
give this type a name. 

newtype Kleisli mab = K(a^mb) 

then we can implement the arrow operations as follows: 

instance Monad m =>■ Arrow (Kleisli m) where 
arr f = K (Xb — > return (/ b)) 
K f^>K g = K (Xb^ fb^g) 

This shows that arrows do indeed generalise monads; for every monad type, 
there is a corresponding arrow type. (Categorically speaking, we just con- 
structed the Kleisli category of the monad m). Of course, we will see later 
that there are also many other, non-monadic implementations of the arrow sig- 
nature. 

4.1 Arrows and Pairs 

However, even though in the case of monads the operators return and ;>= are 
all we need to begin writing useful code, for arrows the analogous operators arr 
and ^> are not sufficient. Even the simple monadic addition function that we 
saw earlier 

add :: Monad m => m Int — > m Int — > m Int 
add x y = x Xu — > y Xv — > return (u + v) 

cannot yet be expressed in an arrow form. Making dependence on an input 
explicit, we see that an analogous definition should take the form 

add :: Arrow a (a b Int) — > (a b Int) — > (a b Int) 
add f g = . . . 

where we must combine / and g in sequence. The only sequencing operator 
available is but / and g do not have the right types to be composed. Indeed, 
the add function needs to save the input of type b across the computation of /, 
so as to be able to supply the same input to g. Likewise the result of / must 
be saved across the computation of g, so that the two results can eventually be 
added together and returned. The arrow combinators so far introduced give us 
no way to save a value across another computation, and so we have no alternative 
but to introduce another combinator. 

We extend the definition of the Arrow class as follows: 
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class Arrow a where 
arr :: (a — > b) — > a 6 c 
(3I>) :: abc^acd^abd 
first :: a 6 c — > a (6, <i) (c, <i) 

The new operator /irsi converts an arrow from b to c into an arrow on pairs, that 
applies its argument to the first component and leaves the second component 
untouched, thus saving its value across a computation. Once again, we can 
implement first for any Kleisli arrow: 

instance Monad m =>■ Arrow (Kleisli m) where 

first (K f) = K (X(b, d) -» / b 3^ Ac ->• return(c, d)) 

Given first, we can define a combinator that applies its argument to the 
second component instead, 

second :: Arrow a => a b c — > a (d, b) (d, c) 
second f = arr swap ^> first / ^> arr swap 
where swap (x,y) = (y,x) 

a combinator which processes both components of a pair, 

(**) :: Arrow a=$abc—>ade—ta (b,d) (c, e) 
f mg = first f ^> second g 

and a combinator which builds a pair from the results of two arrows, 

(Mz) :: Arrow a a b c — > a b d — > a b (c, d) 
f®kg = arr(\b^{b,b))^>{fmg) 

With these definitions the add function is easily completed: 

add :: Arrow a (a b Int) — > (a b Int) — > (a b Int) 
add f g = (/ Mzg)^s> arr (X(u, v) ->• u + v) 

Just as we abstracted the idea of applying a binary operator to the results of 
two monadic computations, by going on to define HftM2, so we can generalise 
the arrow version likewise: 

UftA2 :: Arrow a (b — > c — > d) — > a e b — > a e c — > a e d 
UftA2 op f g = {fmig)^> arr (A(6, c) -> b 'op ' c) 

By this point the reader with a categorical background may have formed the 
impression that arrows with the extended interface implement a category with 
products. After all, we can construct arrows into a pair type using <§fc, and we 
can construct projection arrows as arr fst and arr snd. Beware! In fact, there 
is no reason to expect Haskell's pair type to be a categorical product in the 
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category of arrows, or indeed to expect any categorical product to exist. This 
would require properties such as 

{f®kg)^arrfst=f 

to hold, and in general, since our arrows usually represent computations with 
some sort of effect, laws of this sort are simply false. In this case, the side-effects 
of g are lost on the right hand side. 

The reader may also wonder why we chose to take first as primitive, rather 
than (say) Mz which resembles a well-known categorical operator. There are 
two main reasons for our choice. 

• Firstly, since in general our arrows represent computations with effects, 
evaluation order makes a difference. The definition of / Mz g above is ex- 
plicit about this: the effects of / are composed with the effects of g in 
that order, that is evaluation is left-to- right. The definitions of Mz and ** 
above can be used as algebraic laws by the programmer, laws which cap- 
ture evaluation order. In contrast, had we taken Mz as primitive, then the 
designer of each arrow-based library would have had to choose either left- 
to-right or right-to-left evaluation, with the result that evaluation order 
would probably differ from case to case. This would make the behaviour 
of arrow-based libraries less predictable, and reduce the number of useful 
laws that arrow combinators satisfy. 

• Secondly, first is a simpler operator than <§fc, and in general its implemen- 
tation is around half the size of that of the latter. In practice the imple- 
mentations of arrow combinators can be quite complex, and by making 
the choice we did we reduce the work required to build a new arrow-based 
library appreciably. 

4.2 Arrows and Interpreters 

How awkward is it to program with arrow combinators instead of monadic ones? 
And how expressive are the combinators in each case — are there some kinds 
of program which can be expressed using return and but cannot be written 
at all in terms of arr, ^> and first? We can begin to answer both questions 
by looking at (fragments of) an interpreter based on arrows vs. one based on 
monads. If we can write an interpreter in which program fragments in a certain 
language are interpreted as arrows, then we know that any kind of program 
expressible in the interpreted language can also be expressed in terms of the 
arrow combinators. 

To begin with, we shall consider a tiny language with only variables and 
addition. We represent expressions by the datatype 

data Exp = Var String | Add Exp Exp 
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The value of such an expression is always an integer, but in anticipation of 
making extensions we introduce a separate type of values anyway: 

data Vol = Num Int 

We will also require a type for environments: 

type Env = [(String, Vat)] 

Now, a monadic interpreter maps expressions to computations, represented 
using a monad M. To do so. we introduce an evaluation function 

eval :: Exp -> Env -> M Vol 

which we can define by 

eval (Var s) env = return (lookup s env) 
eval (Add e\ e^) env = UftM2 add (eval e\ env) (eval ei env) 
where add (Num u) (Num v) = Num (u + v) 

An arrow interpreter, on the other hand, maps expressions to computations 
represented as arrows. But what should the input of an arrow denoting an 
expression be? By analogy with the monadic case, it is natural to take the 
input of an expression to be the environment. In an arrow interpreter based on 
arrow type A, we therefore give eval the type 

eval :: Exp -» A Env Val 

We can define eval as follows: 

eval ( Var s) = arr (lookup s) 
eval (Add e\ ei) = UftA2 add (eval e\) (eval 
where add (Num u) (Num v) = Num (u + v) 

As we can see, at least in this small example, the arrow code is by no means 
more awkward than the monadic code. Indeed, often the user of a monadic 
combinator library works more with derived operators such as UftM2 than with 
the operators in the monad signature themselves. Where analogous operators 
can be defined on arrows, arrow programs are essentially the same as monadic 
ones. 

4.2.1 Interpreting Conditionals 

Let us pursue the interpreter example a little further, and add a conditional 
expression to the interpreted language. We extend the expression and value 
types as follows: 

data Exp = . . . | If Exp Exp Exp 
data Val= ...\Bl Bool 
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The monadic interpreter is easy to extend: we add a new case 

eval (If ei ei e^) env = eval e\ env 3= \(Bl b) — > 

if b then eval ei env else eval e?, env 

But the arrow interpreter is more difficult. Certainly we could define 

eval (If e\ ei e-$) = (eval e\ Ml eval ei Ml eval e^) ^> 

arr (X(Bl b, (vi, Vi)) — > if b then V\ else Vi) 

but this doesn't properly capture the meaning of a conditional expression: both 
branches are evaluated, and we just choose between the results. Of course the 
intention is to evaluate just one branch, depending on the value of the boolean. 

And this is the crux of the problem: the arrow combinators provide no 
way to choose between two arrows on the basis of an input. To do so, we are 
obliged to add a new combinator. But this time, we choose to define a new class 
ArrowChoice rather than enlarge the existing Arrow class further. By doing so 
we retain the freedom to define arrow types which do not support a dynamic 
choice combinator; they will simply fail to be instances of our new class. 

The new combinator we want will choose between two arrows on the basis 
of the input, and it makes sense therefore for the input to be of Haskell's sum 
type 

data Either a b = Left a | Right b 

We will define (/ ||| g) to pass Left inputs to / and Right inputs to g, so the type 
of HI will be 

(HI) :: ArrowChoice a=>abd—tacd—ta (Either b c) d 

However, just as we chose to define first as an arrow primitive rather than 
Ml, so we choose a simpler operator than ||| as the primitive method in the 
ArrowChoice class. We define 

class Arrow a =>• ArrowChoice a where 
left :: a b c — > a (Either b d) (Either c d) 

where left f invokes / only on Left inputs, and leaves Right inputs unchanged. 
As usual, we check that we can implement left for Kleisli arrows: 

instance Monad rn =>■ ArrowChoice (Kleisli m) where 
left (K f) = K (\x — > case x of 

Left b — > / b ^= Ac — > return (Left c) 
Right d — > return (Right d)) 

Once we have introduced left, we can define 
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right f = arr mirrors left f ^> arr mirror 
where mirror (Left x) = Right x 
mirror (Right x) = Left x 



f<+>g = left f ^> right g 



/ 1 1 1 9 = (/ <+> d) 3^ arr untag 
where untag (Left x) = x 
untag (Right y) = y 



Now returning to our interpreter, we can at last define the interpretation of 
conditionals: 

eval (If e\ e-i ez) = (eval e\ Ml arr id) 3g> 

arr(X(Bl b, env) — > if b then Left env else Right env) ^> 
(eval e-i | || eval 63) 

This is a little more awkward than the monadic code, but would be much 
simplified by introducing a combinator especially for testing predicates: 

test :: Arrow a a b Bool — > a b (Either b b) 

test f = (f Ml arr id) ^> arr (\(b. x) — > if 6 then Left x else Right x) 

Such a combinator is sufficiently useful that it is reasonable to include it in the 
arrow library, whereupon this case of our interpreter becomes no more compli- 
cated than the monadic version: 

eval (If ei 62 63) = test (eval e\ ^> arr(\(Bl b) — > b)) (eval ei ||| eval 63) 



4.2.2 Interpreting A-Calculus 

Using the combinators we have now introduced, we could go on to write an arrow 
interpreter for a complete first-order functional language. But can we interpret 
higher-order functions? Let us consider adding A-expressions and (call-by-value) 
application to the interpreted language. We extend the type of expressions as 
follows: 



Before we can extend the type Vol, we must decide how to represent function 
values. Since calling a function may have an effect, we cannot interpret functions 
as values of type Val — > Vol. In the monadic interpreter, we can use functions 
whose result is a computation, 



while in the arrow interpreter, we naturally represent functions by arrows: 



data Exp = . . . \ Lam String Exp \ App Exp Exp 



data Val = ... \ Fun (Val -> M Val) 
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data Val = ... \ Fun (A Val Val) 

The monadic eval function is easily extended to handle the new cases: 

eval (Lam x e) env = return (Fun (Xv — > eval e ((x,v) : env))) 

eval (App e\ e^) env = eval e\ env A/ — > eval env Xv — > / v 

But the arrow version proves more difficult. Interpreting A-expressions is un- 
problematic, 

eval (Lam x e) = arr (Xenv — > Fun (arr (Xv — > (x,v) : env) ^> eiia/ e)) 

but application is much harder. If we try to define 

eval (App e\ e?) = ((eval e\ ^> arr (X(Fun f) — > /)) Ml eval e?) app 

for some suitable definition of app, then we find that app must invoke an arrow 
which it receives as an input, and there is no way to do so using the combinators 
so far introduced. There is nothing for it but to introduce another new class: 

class Arrow a ArrowApply a where 
app :: a (a b c,b) c 

whereupon the definition of eval above works. So, given an implementation of 
app, we can write an interpreter for the A-calculus, and so we can also express 
other arrow programs in a higher-order style. Once more, it is easy to implement 
app for Kleisli arrows: 

instance Monad rn ArrowApply (Kleisli m) where 
app = K (X(K /,£)-> / x) 

We have now seen that, given a monad to, we can define a corresponding 
arrow type Kleisli to which moreover supports all the other combinators we have 
introduced so far. Conversely, it turns out that, given an arrow type a which 
also supports app, we can define a corresponding monad type ArrowMonad a. 
The definition is simply 

newtype ArrowApply a => ArrowMonad a b = M (a Void b) 

where Void is Haskell's one-point type, whose only element is undefined. That 
is, a 'monadic' computation based on a is simply an arrow which ignores its 
input. We can now define the monad operations on ArrowMonad a: 

instance ArrowApply a Monad (ArrowMonad a) where 
return x = M (arr (Xz — > x)) 
Mto>=/ = M( m^> 

arr (Xx — > let M h = f x in (h, undefined)) ^> 

app) 
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We need app in order to invoke the arrow that the second argument of 
produces. 

One conclusion we can draw from this is that arrow types which support app 
are just as expressive as monads. In principle one might eliminate the concept 
of a monad from Haskell altogether, and replace it with arrows supporting app. 
But another conclusion to draw is that arrows supporting app are really of little 
interest to us here. Our motivation, after all, is to find a generic interface for 
combinator libraries which cannot be based on a monad. But clearly, any library 
which supports an arrow type with app could equally well be given a monadic 
interface. In the rest of the paper, therefore, we will be most interested in arrow 
types which cannot be made instances of Arrow Apply. 

5 Swierstra and Duponcheel's Parsers as Arrows 

Now that we have introduced a number of arrow classes, let us return to Swier- 
stra and Duponcheel's parsers. Recall that we defined their parser type as 

data StaticParser s = SP Bool [s] 

newtype DynamicParser s a = DP ([s] — > (a, [s])) 

data Parser s a = P (StaticParser s) (DynamicParser s a) 

We were unable to make Parser into a monad, but can we make it into an arrow 
type? 

To do so, we will need to add an extra type parameter, since arrow types 
take two parameters, whereas monad types take only one. Our intention is that 
the static properties of a parser should not depend on parse-time inputs, so let 
us change only the type of the dynamic parsing function: 

newtype DynamicParser s a b = DP ((a, [s]) — > (b, [s])) 

data Parser s a b = P (StaticParser s) (DynamicParser s a b) 

Implementing the arrow combinators for this type is now straightforward: 

instance Arrow (Parser s) where 

arrf = P (SP True []) (DP (X(b, s) -» (/ 6, s))) 

P (SP empty 1 starter s\) (DP pi) ^> P (SP empty 2 starters 2 ) (DP p 2 ) = 
P (SP (empty \ A empty 2 ) 

(startersi 'union' if empty 1 then starters 2 else [])) 
(DP(p 2 o Pl )) 

first (P sp (DPp)) = 

P sp (X((b, d), s) -» let (c, s') = p (b, s) in ((c, d),s')) 
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It is easy to modify the definitions from section 3 of symbol, the failure 
operator zero, and the choice combinator -H-, to handle the arrows' input appro- 
priately. Of course, since zero and -H- are overloaded names for monad operators, 
then we cannot use the same names for the corresponding operators on arrows. 
We therefore introduce two further arrow classes, 

class Arrow a =>■ ArrowZero a where 
zero Arrow :: a b c 

class ArrowZero a =>• ArrowPlus a where 
(-W-) :: abc^abc^abc 

and declare Parser s to be an instance of these classes instead. Having done 
so, we can go on to define all the operators in the interface that Swierstra 
and Duponcheel use, in terms of the arrow operations already introduced. For 
example, their sequencing operator is definable by 

(<$>) :: Parser s a (b — > c) — > Parser s a b — > Parser sac 
(<$>) = UftA2 (Xfx -> fx) 

So the user of an arrow-based parsing library can use it in exactly the same way 
as Swierstra and Duponcheel's original library, but in addition can combine 
parsers with generic arrow code. 

What, then, of the other arrow classes, ArrowChoice and ArrowApply? A 
moment's thought shows that parsers cannot support these signatures. The 
choice operator / 1 1 1 g is supposed to make a dynamic choice between two arrows 
on the basis of the input, which implies that the possible starting symbols of 
/ HI g would depend on the arrow's input. But we have deliberately designed the 
Parser type so that the value of the input cannot affect the static component. It 
follows that HI is unimplementable. A similar argument shows that app is also 
unimplementable (indeed, any arrow type which supports app can also support 
choice; to see this, give a definition of left in terms of app). Luckily this does not 
matter: it is rare that we want to write a parser which decides on the grammar 
to accept on the basis of previously parsed values. 

What we see here is that the arrow interface lets the programmer make finer 
distinctions than the monad interface does: we can distinguish between types of 
computations that permit dynamic choices and calls of dynamic functions, and 
types of computations that do not. Swierstra and Duponcheel parsers do not. In 
contrast, once we declare a type to be a monad, we open the possibility of doing 
everything with it. And this is why the monadic interface is too restrictive. 

6 Stream Processors: Processes as Arrows 

We have already seen that any monad gives rise to a corresponding arrow type in 
a natural way, and that Swierstra and Duponcheel's parsers (or more generally, 
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combinators which collect static information about computations) can also be 
represented as arrows. In this section we will show that yet another 'non- 
monadic' notion of computation, namely that of a process, fits naturally into 
the arrow framework. 

We concern ourselves for the time being with processes that have one input 
channel and one output channel. Such processes can be modelled in a purely 
functional language by stream processors. A stream processor maps a stream 
of input messages into a stream of output messages, but is represented by an 
abstract data type. Let SP a 6 be the type of stream processors with inputs of 
type a and outputs of type b. Stream processors are then constructed using the 
operators 

put:: b^SPab^SPab 

which constructs a stream processor which outputs the b and then behaves like 
the second argument, and 

get:: (a -» SP a b) -» SP a b 

which constructs a stream processor which waits for an input, passes it to its 
function argument, and then behaves like the result. For simplicity we shall only 
consider non-terminating (recursively defined) stream processors; otherwise we 
would add another operator to construct a stream processor which halts. 

Stream processors can be represented in several different ways, but quite a 
good choice is as a datatype with put and get as constructors: 

data SPab= Putb (SP a b) \ Get (a -» SP a b) 
put = Put 
get = Get 

Now we can write single processes using put and get, but to put processes to- 
gether we need further combinators. 

The arrow combinators turn out to represent very natural operations on 
processes! For readability we present them separately rather than as one large 
instance definition. The arr operator builds a stateless process that just applies 
a given function to its inputs to produce its outputs. 

arr f = Get (Ax — > Put (f x) (arr /)) 

The ^> operator connects two processes in series: 

sp 1 ^> Put c sp 2 = Put c (sp 1 ^> sp 2 ) 

Put b sp 1 ^> Get f = sp 1 ^> f b 

Get /i ;» Get f 2 = Get (Xa -» /i a 3S> Get f 2 ) 

Notice that we define process composition lazily: the composition blocks waiting 
for an input only if both its constituent processes do. 
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Finally the first operator builds a process that feeds the first components of 
its inputs through its argument process, while the second components bypass 
the argument process and are recombined with its outputs. But what if the 
argument process does not produce one output per input? Our solution is to 
buffer the unconsumed inputs until corresponding outputs are produced. The 
function bypass takes as an additional argument the queue of second components 
waiting to bypass /: 

first f = bypass [] / 

bypass ds (Get f) = Get (X(b,d) -» bypass (ds-tt-[d\) (f b)) 

bypass (d : ds) (Put c sp) = Put (c, d) (bypass ds sp) 

bypass [] (Put c sp) = Get (\(b.d) — > Put (c. d) (bypass [] sp)) 

With this definition. / <§fc g combines / and g in parallel, synchronising their 
output streams to produce a stream of pairs (and also synchronising their joint 
output with the input stream). 

We can now use generic arrow combinators to write down stream processors. 
For example, the following stream processor outputs Fibonacci numbers: 

fibs = put 0 fibs' 

fibs' = put 1 (UftA2 (+) fibs fibs') 

Stream processors also support a natural notion of failure: a failing process 
simply never produces more output. We can therefore define a zeroArrow as 

instance ArrowZero SP where 

zeroArrow = Get (Ax — > zeroArrow) 

We define p-Wi-q to run p and q in parallel, merging their outputs. 

instance ArrowPlus SP where 

Put b sp 1 -#• sp 2 = Put b (sp 1 -#• sp 2 ) 
spi -#• Put b sp 2 = Put b (sp 1 -Wr sp 2 ) 
Get A * Get f 2 = Get (Xa -}/iO# f 2 a) 

We take care to define parallel composition lazily also, so that p -Hf- q blocks 
waiting for input only if both p and q do. 
These definitions satisfy the laws 

zeroArrow -Hf q = q 
p -Hf zeroArrow = p 

(p J ^q) J i^r = p^(q^r) 

which is a strong indication that they are reasonable. 

Stream processors can also support dynamic choice. The stream processor 
left sp simply passes messages tagged Left through sp, while others are passed 
on directly. 
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instance ArrowChoice SP where 



left (Put c sp) = Put (Left c) (left sp) 
left (Get f) = Get (\z — > case z of 



Left a -> left (f a) 

Right b -» Put (Right b) (left (Get /))) 



With this definition, then f \\\g can be regarded as yet another kind of parallel 
composition, which routes inputs tagged Left to / and inputs tagged Right to 



In fact, although stream processors have only one input and one output 
channel, we can model processes with many of each by multiplexing several 
channels onto one. For example, we can regard a channel carrying messages 
of type Either a b as a representation for two channels, one carrying as and 
the other carrying 6s. With this viewpoint, / ||| g combines / and g in parallel 
to yield a stream processor with two input channels (multiplexed onto one), 
and merges the output channels onto one. Should we wish to combine / and 
g without merging their outputs, we can instead use / <+> g. We can copy an 
input channel to two output channels using arr Left -Hf arr Right, and so we can 
define a parallel combination of / and g with two output channels, but which 
copies one input channel to both processes by 



We can write a stream processor with two input channels and one output, 
that just copies the first input channel and discards the second, or vice versa, 
as 



Not surprisingly, combining two processes and then discarding the output chan- 
nel from one of them is equivalent to the other: 



But these properties have a categorical interpretation: they tell us that the 
Either type is a weak categorical product in the category of stream processors! 
(Only weak, because there is more than one way to define |& so that these 
equations hold; our definition favours g over / in case both produce outputs 
simultaneously). In a deep sense, then, the Either type behaves more like a 
product than the pair type does, when we work with stream processors. And 
indeed, a channel carrying a sum type corresponds much more closely to a pair 
of channels than does a channel carrying pairs. 
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f\k\g= (arr Left-\fr arr Right) ^>(f <+> g) 




(f\k\g)^justLeft = f 
(f |&| g) ^> justRight = g 
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The only arrow class we have not yet shown how to implement is ArrowApply. 
But it turns out that there is no sensible definition of 

app :: SP (SP a b,a) b 

Since app would receive a new stream processor to invoke with every input, there 
is no real sense in which the stream processors it is passed would receive a stream 
of inputs; we could supply them with only one input each. This would really 
be very unnatural. Since stream processors do not support a natural definition 
of app, they cannot either be fitted into the monadic framework. They thus 
give us our second example of a useful kind of computation which cannot be 
represented as a monad. 

However, recalling that Either may play the role of a product type for stream 
processors, we might instead of app consider looking for a function of type 

dyn :: SP (Either (SP a b) a) b 

There is actually a very natural definition with this type: the 'dynamic stream 
processor' dyn receives stream processors on its first input channel, and then 
passes inputs from its second input channel through the stream processor re- 
ceived, until it receives another stream processor to replace the first. We imple- 
ment it as 

dyn = dynloop zeroArrow 

where dynloop (Put b sp) = Put b (dynloop sp) 
dynloop (Get /) = Get (\z — > 
case z of 

Right a — > dynloop (f a) 
Left sp — > dynloop sp) 

Stream processors are not just amusing toys: they are at the heart of the 
fudgets combinator library for programming graphical user interfaces [CH93]. 
A fudget from a to b is like a stream processor with two extra hidden commu- 
nication channels, to and from the window manager. A fudget can therefore 
exchange high-level messages with other fudgets, but can also manage a part 
of the screen. Thus a fudget has both an appearance and a behaviour, which 
makes them useful for structuring complex user interfaces. 

The fudget type F a b is actually implemented as a stream processor in 
which the high and low level communication channels are multiplexed onto one, 
in just the way we described. Since fudgets are just stream processors, they can 
also be declared to be arrows, supporting the same operations. Interestingly, 
almost all the operations we discussed in this section do indeed appear in the 
fudgets library — even dyn — although of course, they appear with different 
names, and not as instances of a general framework. 



24 



7 Functors: New Arrows from Old 



One of the attractive features of monads is that they can be designed system- 
atically, using so-called monad transformers [LHJ95]. A monad transformer is 
a monad parameterised on another monad, such that computations over the 
parameter monad can be 'lifted' to computations over the new one. 

For example, the state monad of section 2.2 can be generalised to a monad 
transformer: 

newtype StateMonadT s m a = SM (s — > m (a, s)) 

In general the monad operators on the new type must be defined in terms of 
the monad operators on the parameter monad, as in this case: 

instance Monad m => Monad (StateMonadT s m) where 
return a = SM (As — > return (a. s)) 
a; »= / = SM (As -> let SM x' = x in 
x' s »= A(a, s') -» 
let SM f = f a in 
/' s') 

Lifting of computations is defined by passing the state through unchanged: 

UftState :: Monad m => m a — > StateMonadT s m a 
liftState x = SM (As — > x ;>= Xa — > return (a, s)) 

Finally, the new monad supports fetch and store operations, just like the original 
state monad: 

fetch :: Monad rn => StateMonad s m s 
fetch = SM (As — > return (s, s)) 

store :: Monad m => s — > StateMonad s m () 
store a: = 5M (As — > return (Q,x)) 

The new monad thus supports all the computations of the parameter monad 
(by lifting), and in addition manages a state. By composing monad transform- 
ers together, one can build up a monad providing any desired combination of 
features. For example, if we want a monad which manages a state and handles 
failures, we can use the type StateMonadT s Maybe. 

In this section we show that arrows have the same property: we can define 
'arrow transformers' which map simpler arrow types to more complex ones. 
The most important monad transformers have arrow transformer counterparts, 
and we will describe those for handling failures, state, and continuations. An 
arrow transformer is, by analogy with a monad transformer, just an arrow type 
parameterised on another arrow type, such that arrows of the second type can 
be mapped into arrows of the first. But in fact, this corresponds closely to the 
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standard categorical notion of a functor, and so from now on we shall use the 
word functor instead of arrow transformer. 

We note briefly that the concepts of monad transformers and functors can 
be formalised as classes, thus overloading the lifting operations, but that this 
requires a much more powerful class system than Haskell currently supports. 
We therefore refrain from doing so. 

7.1 The Maybe Functor 

Any arrow type can be lifted to an arrow type supporting failures by the functor 

newtype MaybeFunctor a b c = MF (a b (Maybe c)) 

That is, we use arrows whose result can indicate failure. We can lift arrows to 
this type using 

UftMaybe :: Arrow a => a b c — > MaybeFunctor a b c 
KftMaybe f = MF (f ^> arr Just) 

The arrow operations need to handle failures, which means they need to make 
dynamic decisions. We therefore must require that the parameter arrow type 
supports choice: 



instance ArrowChoice a => Arrow (MaybeFunctor a) where 



arr f = UftMaybe (arr /) 

MF f^MF g = MF ( f ■» 

arr (Xz — > case z of 

Just c — > Left c 

Nothing — > Right Nothing) ^> 

(g HI arr id)) 



first (MF /) = MF ( first f ^> 

arr (\(c',d) — > case c' of 

Just c — > Just (c, d) 

Nothing — > Nothing)) 

Arrows formed by MaybeFunctor support failure and failure handling, of 
course: 
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instance ArrowChoice a => ArrowZero (MaybeFunctor a) where 
zero Arrow = MF (arr (Xz — > Nothing)) 

instance ArrowChoice a ArrowPlus (MaybeFunctor a) where 
MF f ■#- MF g = MF ( (/ Ml arr id) :» 

arr (X(c',b) — > case c' of 

Jms£ c — > ie/t c' 
Nothing -» i?igfti 6) ^> 

(arr id 1 1 1 #)) 

and they also, not surprisingly, support choice: 

instance ArrowChoice a ArrowChoice (MaybeFunctor a) where 
MF / HI MFg = MF(f \\\g) 

Finally, if the underlying arrows support application, then so do the arrows 
produced by MaybeFunctor: 

instance (ArrowChoice a, ArrowApply a) ArrowApply (MaybeFunctor a) where 
app = MF (arr (X(MF f, b) ->• (/, 6)) ^> app) 

7.2 The State Functor 

Any arrow type can be lifted to an arrow type supporting state passing by the 
functor 

newtype StateFunctor s a b c = SF (a (b, s) (c, s)) 

We can lift arrows to this type using 

liftState :: Arrow a a b c — > StateFunctor s a b c 
UftState f = SF (first f) 

The arrow operations just pass the state along as one would expect: 

instance Arrow a => Arrow (StateFunctor s a) where 
arr f = liftState (arr f) 
SFf^>SFg = SF(f^>g) 

first (SF /) = SF( arr(X((b,d),s) -> ((&, a),d)) » 
first f ;» 

arr (X((c,s),d) -> ((c,d),s))) 

Of course, the arrows produced by the StateFunctor support fetch and store 
operations: 
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fetch :: Arrow a =>• StateFunctor sabs 
fetch = SF (arr (X(b, s) -» (s. s))) 



store :: ^rrow a =>• StateFunctor s a s () 
store = (arr (A(x, s) -» 

Stateful arrows inherit the ability to support dynamic choice, failure, and 
failure handling from the parameter arrow: 

instance ArrowChoice a => ArrowChoice (StateFunctor s a) where 
left (SF f) = SF( arr (\(z, s) -» case z of 

Left b -» Left (b, s) 
Right c — > Right (c, s)) ^> 
((f^ first (arr Left)) \ \\ first (arr Right))) 

instance ArrowZero a =>• ArrowZero (StateFunctor s a) where 
zeroArrow = SF zeroArrow 

instance ArrowPlus a => ArrowPlus (StateFunctor s a) where 
SF f-M-SFg = SF(f^g) 

Finally, if the underlying arrow type supports application, then so do stateful 
arrows based on it: 

instance ArrowApply a =>• ArrowApply (StateFunctor s a) where 
app = SF (arr (X((SF f, b),s) -> (/, (b, s))) » app) 

The state functor we have defined is of course closely related to the state 
monad transformer, but the advantage of defining functors on arrows, rather 
than transformers on monads, is that we can apply them to arrow types that 
do not correspond to any monad. As an example, the reader is invited to work 
out the behaviour of arrows of type StateFunctor s SP, derived by adding state 
passing to stream processors. 

7.3 The CPS Functor 

A third well-known monad transformer adds continuation passing to any monad. 
In the monadic world, we can define 

newtype CPS ans rn a = CPS ((a — > m ans) — > m ans) 

so that a computation is represented by a function from a continuation for 
its result (a monadic function into an answer type) to the computation of the 
answer. In the world of arrows, we can represent a continuation by an arrow, 
rather than a function, and a continuation-passing arrow from b to c as a function 
from the continuation of the result to the continuation of the argument: 

newtype CPSFunctor ans a b c = CPS ((a c ans) — > (a b ans)) 
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Lifting an arrow to the CPS type is straightforward: 

liftCPS :: Arrow a => a b c — > CPSFunctor ans a b c 
UftCPS f = CPS (Xk^ f^> k) 

But now, in order to define the basic arrow operations on CPS arrows, we find 
we already need to use application at the underlying arrow type! 

instance Arrow Apply a => Arrow (CPSFunctor ans a) where 
arr f = liftCPS (arr f) 
CPS / ;» CPS g = CPS (Xk / (g k)) 
first ( CPS /) = 

CPS (Xk -> arr (X(b,d) -> (/ (arr (Ac (c, d)) 3I> k), b)) 3I> app) 

To define first (CPS /) we must invoke / with a continuation which recombines 
its result with the second component of the argument. This we can do, but only 
in the scope of an arr (X(b, d) — > . . .) which binds a name to that second com- 
ponent. We can only construct the arrow representing /'s continuation within 
another arrow, and so we can only contruct the continuation of /'s argument 
within an arrow, which forces us to use app to invoke it. In a way, since con- 
tinuation passing is the epitomy of higher-order programming, this is not really 
surprising. 

CPS arrows inherit the ability to support failures and failure handling from 
the underlying arrow type, and can of course support dynamic choice and ap- 
plication. We will not give the definition here, however. What we will do is 
show how to define a jump operator, which invokes a continuation supplied as 
its input 

jump :: Arrow Apply a => CPSFunctor ans a (a c ans,c) z 
jump = CPS (Xk — > app) 

and a combinator callcc, which passes the current continuation to its argument 
arrow: 

callcc :: Arrow Apply a => 

(a c ans — > CPSFunctor ans a b c) — > CPSFunctor ans a b c 
callcc f = CPS (Xk -> let CPS g = f k in g k) 

As we have seen, continuation passing arrows always support application, 
and must be based on an underlying arrow type which also supports application. 
Thus both the argument and the resulting arrow types correspond to monads. 
Our CPS functor is therefore no more general than the CPS monad transformer, 
but nonetheless, what we have shown is that we can work entirely with arrows 
even if we want to use continuation passing style. 
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8 Arrow Laws 



Up to this point we have ignored the matter of laws. In fact the presentation 
of monads in section 2 was a little oversimplified: an implementation of return 
and >*= constitutes a monad only if the so-called monad laws are satisfied: 

return x ;>= f = f x 

m 3= return = m 
(m »=/)»= g = m > (Ai -> / i » 9) 

These laws state in essense that sequential composition is associative, and return 
is its unit, although they are complicated slightly by the need to pass values 
from one computation to the next. The programmer relies implicitly on the 
monad laws every time he or she uses a monad based library without worrying 
about how to bracket sequential compositions. 

We will place similar requirements on the implementations of the arrow 
combinators. But since there are many more arrow combinators than monadic 
ones, we will require a larger collection of laws. All of the laws that we state in 
this section are satisfied by Kleisli arrows. 

We can simplify the statements of the laws a little by noting that the ordinary 
function type can be declared to be an arrow: 

instance Arrow (— >) where 
arr f = / 

/ ^>9 = 9 ° f 

first f = X(b,c) -> (/ b,c) 

instance ArrowChoice (— >) where 
left f (Left b) = Left (f b) 
left f (Right d) = Right d 

instance ArrowApply (— >) where 
app = \(f,x) -» / x 

Of course, we will require composition to be associative, and moreover to be 
preserved by arr: 

(f^g)^h = /3§>( ff 3§>/i) 
arr (/ ^> g) = arr f ^> arr g 

We will require an extensionality principle for arrows, that arrows which 'behave 
the same' for all inputs really are equal. We can formulate this as a law as 
follows: 

arr h ^> / = arr h ^> g 
h is onto 
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Dually 

/ ^> arr h = g ^> arr h 
h is one-to-one 

It follows that 

arr id^> f = f = f ^> arr id 

(by composing on each side with arr id, since id is both one-to-one and onto). 
Categorically speaking, we now know that arrows form a category, and that arr 
is a functor from the category of Haskell functions to the category of arrows. 

These laws correspond in some sense to the monad laws, but now we must 
go on to state the laws that the other arrow combinators are required to satisfy. 
Let us call an arrow pure if it is equal to arr f for some /: a pure arrow 'has 
no side-effects'. We shall require that all combinators behave for pure arrows 
as they do for functions; that is: 

first (arr /) = arr (first /) 
left (arr /) = arr (left f) 

Furthermore we require that our combinators preserve composition: 

first (/ 3S> ff) = first f ^> first g 
left (/ 3§> ff) = left f 3§> left g 

Similar properties for second and right follow as easy consequences. 
Notice, though, that it does not follow that 

(/ m g) ^>(h =w* k) = (f 3I> h) m(g ^> k) 

since the order of g and h differs on the two sides. This is another reason to 
favour first and left as primitives over their more usual binary counterparts: the 
laws they must satisfy become much simpler to state. 

We formalise the property that first f depends only on first components of 
pairs as follows: 

first f ^> arr fst = arr fst ^> / 

but it is not in general true that 

first f ^> arr snd = arr snd 

since, on the right hand side, the side-effects of / are lost. Instead we formalise 
the intuition that the second component of a pair is unaffected by first f as a 
law that allows a function of that second component to be moved across the 
use of first. We have to require that the function be pure, to avoid potentially 
changing the order in which side-effects occur. Thus the law becomes 

first f second (arr g) = second (arr g) ^> first f 
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Once again, the dual statement, in which first and second are interchanged, 
follows as an easy corollary. 

We note in passing that many categorical properties of products fail in the 
presence of side effects. For example, the reader might expect that 

f^(gMih) = (f 2* h) 8k(f h) 

but this is not true (unless / is pure) because the side-effects of / are duplicated 
on the right. 

The laws for first serve as models for the laws for left: we require that 

arr Left ^> left f = / ^> arr Left 
right (arr g) ^> left f = left f ^> right (arr g) 

Note here also that we cannot change the order of left f and right g unless 
we know that one of / or g is pure, because we might change the order of 
side-effects. 

For arrows supporting application, we require firstly that 'currying' and then 
applying the identity arrow is equivalent to the identity (on pairs): 

first (arr (Xx — > arr (Ay — > (x, y)))) ^> app = arr id 

Secondly, we require a kind of parametricity property for app, which permits 
operations to be moved in or out of the applied arrow: 

first (arr (g ^>)) 3I> app = second g ^> app 
first (arr (^> h)) ^> app = app ^> h 

From these laws we can prove an analogue of ^-conversion, that applying a 
constant arrow using app is equivalent to the arrow itself: 

arr (Xx — > (/, x)) ^> app = f 

Moreover, currying and then applying any arrow is equivalent to the arrow: 

first (arr (Xx — > arr (Xy — > (x, y)) ^> /)) ^> app = f 

Finally, we can prove that the monad laws hold for the ArrowMonad defined in 
section 4.2.2. 

For the remaining arrow classes, ArrowZero and ArrowPlus, we just require 
that -Hf is associative, and zeroArrow is its unit. Stronger conditions, such as 
for example 

zeroArrow ^> / = zeroArrow 

would be overly restrictive: this property fails for stream processors, for exam- 
ple, since / may very well produce outputs independently of its input. 
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In general, there is something of a conflict between the desire on the one 
hand to state many laws, thus making it possible to prove strong properties 
generically, for every kind of arrow, and the wish on the other hand to leave open 
the possibility of very many different implementations of the arrow signature. 
We believe that the laws we have stated in this section are a rather minimal set, 
which every reasonable arrow type should satisfy. 

9 Active Web Pages: CGI Programs as Arrows 

So for in this paper we have shown how the arrow interface can generalise a 
variety of existing combinator libraries. In this section we shall discuss a library 
we are currently developing, which was inspired by the concept of arrows. 

The application that this library addresses is that of constructing active 
web pages, that is, pages that may appear differently each time they are visited. 
Active web pages are represented by programs, which may run either in the 
client browser (applets) or on the web server. Quite different technologies are 
used in each case; we concern ourselves here with programs which run on a web 
server. Such programs can query a database held on the server, allow clients to 
upload new data, and so on. Even rather simple programs can be very useful: 
for example, those which enable students to book meetings with a teacher, or 
researchers to submit articles to conferences. 

Active web pages of this sort are implemented by so-called CGI programs 
stored on the server. When a client accesses the URL of the program, then 
it is run on the server, and the output from the program (usually HTML) is 
sent back to the client browser. There are a couple of different mechanisms for 
sending data from the client to the CGI program: the one we will consider sends 
an encoding of the fields of an HTML form to the web server, along with the 
request to run the program. CGI stands for Common Gateway Interface, the 
protocol governing the form in which data is sent to and fro between the client 
and the server. 

Unfortunately, this mechanism is awkward to use in practice. Normally, the 
implementor of a CGI program wishes to lead the remote client through a series 
of interactions, for example first asking a student to identify him or herself, 
then offering a choice of meeting times, then confirming that a time has been 
booked. But interactions with the client can only take place in between runs 
of CGI programs. To ask the client a question, a CGI program must output 
the question as an HTML form, and terminate. When the client answers the 
question by filling in and submitting the form, then in general a different CGI 
program is run to accept and process the answer. This leads to poor modularity, 
because the format of the form (field names, etc) must be known both to the 
program which creates it, and to the program which interprets its contents. But 
a more severe problem is that the state of the CGI program is lost across the 
interaction. 



33 



It is therefore necessary to save the state of the CGI program explicitly across 
each interaction. This cannot be done on the server! It is by no means certain 
that the client ever will submit a reply, so that if the state were saved on the 
server then it might remain there for ever, waiting for a reply that never came. 
On the other hand, the client might submit a reply, then use the 'Back' button 
in the browser, and reply to the same question again! If second and subsequent 
replies are to be handled properly, then the state cannot be discarded even once 
a reply has been received. 

The solution is to store the state of the CGI program on the client, along 
with the question. When the client submits an answer, then the state is returned 
along with it, permitting the CGI program to pick up from the same point that 
it left off. One can think of this state as a kind of continuation: when a CGI 
program wishes to ask the client something, it captures its current continuation 
and sends it along with the question to the client, and when the client replies 
then the continuation is returned to the server, and can be invoked to handle 
the reply. HTML provides a mechanism for handling such data: an HTML form 
can contain 'hidden fields' whose contents are returned unchanged to the server 
when the form is filled in and submitted. Unfortunately, though, HTML fields 
cannot contain function values, and so we must find a different way to represent 
continuations if we are to use this idea. 

The combinator library I am developing takes care of suspension of com- 
putations, saving of state, and restart from the same point. It lets the CGI 
programmer view interaction with the client as a procedure call; there is an 
arrow 

ask :: CGI String String 

which maps a question to the client's answer. Thus programs which conduct a 
series of interactions can be implemented very simply. For example, consider a 
program which asks the client 

What is your question? 

expecting to recieve a reply such as 
How old are you? 

and then asks the client the same question, taking the client's answer, and then 
finally sending the client a result such as 

The answer to "How old are you?" is 40. 

Such a program can be implemented by the arrow 

arr (\z — > "What is your question?") ^> ask^> 
(arr id Ml ask) :» 

arr (X(q,a) — > "The answer to \ "" -H-q-H- "\" is "-H-a) 
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Why choose the arrow interface rather than the monad interface for this 
problem? The key observation guiding the choice was that the combinators need 
to save the entire state of the program at an ask operation, which is difficult 
because a part of the program state may be held in free variables. We need only 
be concerned here with variables bound to the results of computations, since it 
is only these that may have a different value the next time the program is run. 
The monadic interface permits such variables to scope over computations, and 
in particular over ask operations, which means that their values must be part of 
the saved state. But the arrow interface does not permit this: the only way to 
bind a variable to the result of a computation is with the arr combinator, but 
then the scope of the variable cannot extend over an ask operation. 

How, then, can CGI arrows be represented? When such an arrow is invoked, 
it may either terminate normally, producing a result, or it may suspend at an 
ask operation. On suspension, an arrow must produce a state to save, and a 
question to ask. A CGI arrow can also be entered in two different ways: it may 
either be entered normally, with an argument, or it may be resumed from an 
ask. In the latter case we must supply a state to resume from, and the answer 
to the question. A natural representation for CGI arrows might therefore be 

newtype CGI b c = CGI (Either b (State, String) — > Either c (State, String)) 

However, in general a CGI program may have side-effects on the server, which 
this type does not allow for. So we shall instead represent CGI arrows as arrows 
between these two types, which in practice will be arrows which can perform 
I/O. We shall parameterise our definitions on the underlying arrow type, and 
so define a CGI functor: 

newtype CGIFunctor a b c = 

CGI (a (Either b (State, String)) (Either c (State, String))) 

Now we can define 

type CGI bc = CGIFunctor (Kleisli 10) b c 

With this definition, the ask operation is easily defined: it suspends when 
entered normally, and delivers the answer as its result when it is resumed. No 
state is needed to resume the ask operator itself, so we assume that the State 
type includes a constructor Empty: 

data State = Empty | . . . 

We define ask as follows: 

ask :: ArrowChoice a CGIFunctor a String String 

ask = CGI (arr (Xq — > Right (Empty, q)) \ \\ arr (X(Empty.a) — > Left a)) 
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The first alternative here handles a normal entry, and suspends to ask the 
question q, while the second alternative handles a resumption, and delivers the 
answer a as the arrow's result. 

The arr operator is also easily defined: a pure arrow can never suspend, 
and therefore can never be resumed either, so we need consider only the Left 
summands here. 

arr :: Arrow a =>(&—>• c) — » CGIFunctor a b c 
arr f = CGI (arr (\(Left b) -> Left (/ &))) 

It is when we define arrow composition that we first need to make use of the 
state. A composition of arrows may suspend either in the first arrow, or in the 
second, and the state that we save must record which case applied. Similarly, 
when we resume a composition of arrows, then we need to know which arrow to 
resume. We shall therefore extend the State type to record this information: 

data State = Empty | InLeft State | InRight State 

The definition of composition then becomes 



(^>) :: ArrowChoice a =>• 

CGIFunctor a b c -> CGIFunctor a c d -» CGIFunctor a b d 
CGI f ^ CGI g = CGI ( ( arr Left ^> enterf) 1 1 

( (arr (A(s, a) — > 
case s of 

InLeft s 1 -» Left (Right (s 1 , a)) 
InRight s' -» Right (Right (s' , a)))) 3S> 
(enter/1 1 1 enterg))) 
where enterf = f ^>( (arr Left^> enterg) ||| 

(arr (A(s, q) — > Right (InLeft s, q)))) 
enterg = g ^> ( arr Left \ \ \ arr (\(s,q) — > Right (InRight s , q))) 

The first case in ^> handles initial entry to the composition, and just makes an 
initial entry to /. The second case handles resumption: it tests to see which of 
/ and g should be resumed, and sends a resumption state to the appropriate 
one. Arrow enterf invokes /, and if / terminates normally, makes an initial 
entry to g. If / suspends, on the other hand, then enterf records that the 
suspension occurred in the left operand of ^>. Arrow enterg similarly records 
that a suspension in g occurred in the right operand of ^>. Thus we always 
record in which arrow a suspension occurred, and on resumption we return to 
the same point. 

When we define the first combinator, we need to use the state in a different 
way. There is no need to record where a suspension occurred: when first f 
suspends, it must be in the arrow /. However, since first f must preserve 
the second component of its input unchanged, then when we resume after a 
suspension, we need to know what the value of this second component was. We 
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therefore have to save it in the state. One difficulty is that the values to be saved 
can have many different types, at different occurrences of first. We shall convert 
them all to the same type before saving them: since states must eventually be 
embedded in HTML fields, it is convenient to convert them to strings, using 
Haskell's standard function show. When we resume from such a state, we can 
convert the saved value back to its original type using the standard function 
read, which satisfies read o show = id. 

We shall therefore extend the State type again: 

data State = Empty | InLeft State | InRight State | Save String State 

and define first as 

first :: (Arrow a, Show d, Read d) =>• 

CGIFunctor a b c -> CGIFunctor a (b, d) (c, d) 
first (CGI f) = 

CGI ( arr (\x — > case x of 

Left (b,d) -» (Left b,d)) 

Right (Save v s,a) — > (Right (s, a), read v))) ^> 

first f ^ 

arr (\(x, d) — > case x of 

Left c — > Left (c, d) 

Right (s,q) — > Right (Save (show d) s,q))) 

On an initial entry to first f, we just pass the first component of the input to 
/; on a resumption we reconstruct the saved second component from the state. 
On final termination of /, we just pair its output with the second component d, 
but on suspension we save d in the state. Notice that the type d must support 
read and show operations, which not all types do. This is recorded in the type 
signature of first, which requires d to be an instance of the classes Read and 
Show. 

CGI arrows also permit dynamic choices. Implementing left turns out to be 
particularly simple, because left f can suspend only if the input was of the form 
Left b; we therefore don't need to record any additional information in the state 
to allow us to decide whether or not to invoke / on a resumption. 



37 



left :: ArrowChoice a =>• 

CGIFunctor a b c — > CGIFunctor a (Either b d) (Either c d) 
left (CGI /) = 

CGI ( arr (\x — > case a; of 

Left (Left b) -> Le/£ (Le# fo) 

Le/t (Right d) — > Right d 

Right (s,a) -» Ze/f (Right (s,a))) ^> 

leftf?* 

arr (\x — > case a; of 

Le/t (Le/£ c) -» Le/t (Le/£ c) 

Left (Right (s , q)) — > Right (s,q) 

Right d -» Left (Right d))) 

On an initial entry to Ze/f /, we pass inputs tagged Ze/f to /, and those tagged 
Right are passed through unchanged. On a resumption of left f, we just resume 
/. When / terminates normally, or the input was tagged Right, then left f 
terminates. When / suspends then so does left f . in the same state. 

It is also possible to give an appealing interpretation of zeroArrow and -#- 
for CGI arrows: / ■#■ g creates two threads which run in parallel, and zeroArrow 
terminates a thread. We use this mechanism to enable a CGI arrow to ask 
several questions in one interaction (if both / and g suspend). We omit the 
details here. 

It is not possible, however, to implement app. The difficulty here is that 
the types that CGI arrows operate over must support read and show, so that 
intermediate values can be saved on the client. CGI arrows themselves are 
implemented in terms of functions, and so cannot be read and written. Therefore 
a CGI arrow cannot take another CGI arrow in its input, and app cannot be 
defined. 

The library I am developing is based on the ideas in this section, but is 
necessarily a little more complicated. It is an oversimplification to consider the 
communication with the client to consist of a single question and answer, or 
even multiple questions and answers. In reality the client is sent an HTML 
page containing one or more HTML forms, each of which may contain many 
fields. The full-scale library includes combinators for generating various HTML 
elements, and for putting parts of forms together into larger forms. There is 
also a 'top-level' function 

serveCGI:: CGI a b -» 10 () 

which takes an arrow and 'runs it', taking care of encoding states in hidden 
fields, decoding the data returning from the client, and so on. 

One major irritation which we have so far glossed over is that CGI arrows 
cannot actually be made an instance of the Arrow class defined in this paper! 
The problem lies in the types of the arrow methods given in this section. Look 
back at the type of first: it requires that the type of the value to be saved be an 
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instance of the Read and Show classes. The type given for first in the definition 
of the Arrow class makes no such restriction. Therefore this implementation of 
first cannot be declared to be an instance of the generic one — it is less general. 

We might attempt to solve this problem by moving the restriction to a 
different place. Let us define the CGI arrow type so that it is only applicable 
to types in these classes: 

newtype (Read b, Show b, Read c, Show c) => 
CGIFunctor a b c = 

CGI (a (Either b (State. String)) (Either c (State. String))) 

In categorical terms, we define a new category whose arrows are CGI arrows, 
and whose objects are a subset of the Haskell types, namely those supporting 
read and show. Now, since the implementation of first given in this section 
constructs a CGI arrow from (b, d) to (c, d), then it is evident that the type d 
must support read and show, and there is no need to explicitly require that in 
the type of first. As a result, it should now be possible to declare CGI arrows 
an instance of the generic arrow class. 

Unfortunately, this does not work. The Haskell type system requires the 
restrictions on d in the type of first, even if we declare that they are satisfied for 
all CGI arrows. Haskell does not infer from the occurrence of a type CGI b c, 
that b and c must be instances of Read and Show — and indeed, this is not 
even true, because of the way that type restrictions on datatype definitions are 
interpreted. I consider this to be a defect of the Haskell type system, which 
hopefully can be corrected in a future version of the language. 

In the absence of such a correction, we are obliged to make a copy of the 
arrow library, and all the generic code that uses it, with the only difference that 
the type assigned to first in the Arrow class is the one required for the CGI 
instance. By doing so we can still benefit from using a standard arrow interface 
to the CGI library — we can still combine CGI arrows with other arrow code 
— but any program which uses the CGI library must import a special definition 
of the arrow class, which restricts all arrows in the entire program to work over 
types supporting read and show. This is frustrating indeed. 

Finally, we note with hindsight that a monadic interface could be used in- 
stead here. We could define a monad whose computations can be suspended 
and resumed, in an analogous way to CGI arrows. However, the definition of 
m / would need to record not only which of m or / suspended, but also the 
value that m delivered, if suspension occurred in /. Concretely, the 'InRigM 
form of State would need to carry an extra component, namely the value of m. 
Thus the problem of recording free variables is solved: every free variable of 
an ask operation which is bound to the result of a computation, is bound by an 
occurrence of and we can make that occurrence of responsible for saving 
the value. 

However, even if a monadic interface would be possible, we believe it would 
make for less efficient CGI programs. The monadic library we suggest would 
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need to save every previously delivered value, whereas the arrow library saves 
only those which are still needed. Thus the monadic library would tend to send 
more information to and from the client. Of course, such a monadic library 
would also fall foul of the typing problem just discussed, so that a CGI monad 
could not be declared to be an instance of Haskell's Monad class. Consequently 
it could not be used together with standard monadic functions, or Haskell's 
monadic do syntax. 

10 Conclusions 

This paper proposes the replacement of monads as a structuring tool for com- 
binator libraries, by arrows. We have seen that any monadic library can be 
given an arrow interface instead (via Kleisli arrows), and so the arrow inter- 
face is strictly more general. We have seen that many monadic programming 
techniques have analogues in the world of arrows: monad transformers become 
functors, standard monad constructions for exceptions, state passing and con- 
tinuations carry over to arrows, even generic monadic functions often have an 
arrow analogue. But basing an interface on arrows instead of monads permits 
finer distinctions to be made: we can distinguish between kinds of computa- 
tion which permit dynamic choices to be made, or dynamic computations to be 
invoked, and those which do not. 

The advantage of the arrow interface is that it has a wider class of implemen- 
tations than the monad interface does; it is more general. Thus some libraries 
based on abstract data types which simply are not monads, can nonetheless be 
given an arrow interface. Such libraries include those for processes modelled 
by stream processors or fudgets, libraries for efficient parsing, or in general any 
library which computes static properties of computations in advance of running 
them. So this category includes a number of libraries which are highly useful in 
practice. By giving them an arrow interface, we make it possible to use them 
together with generic arrow code. 

Moreover, some existing monadic libraries might benefit by replacing the 
monads with arrows. One motivation might be in order to introduce the same 
kind of optimisation which Swierstra and Duponcheel used. We believe this 
may be the case for Conal Elliot's animation library [EH97], and for Bjesse et 
als library for hardware design [BCSS98]. 

In short, we believe that arrows offer a useful extension to the generality of 
generic library interfaces. 
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